用并行 Claude 团队构建 C 编译器
官方原文: https://www.anthropic.com/engineering/building-c-compiler
发布日期： 2026年2月5日
作者： Anthropic Safeguards 团队研究员 Nicholas Carlini
概览
本文介绍一项“Agent 团队”实验：多个 Claude 实例在没有持续人工干预的情况下，在同一代码库上并行工作。作者让 16 个 Agent 从零用 Rust 编写一款可编译 Linux kernel 的 C compiler。近 2,000 个 Claude Code session、约 20,000 美元 API 成本后，Agent 团队产出约 100,000 行代码的 compiler，可在 x86、ARM 与 RISC-V 上构建 Linux 6.9。
该 compiler 已开源于 github.com/anthropics/claudes-c-compiler。
让 Claude 长时间运行
现有 Agent scaffold，例如 Claude Code，通常要求操作人员在线。为获得持续、自主的进展，作者制作了一个 harness，把 Claude 放入简单循环：一项任务结束，就立刻接下下一项。Bash script 在 while true 中调用 claude --dangerously-skip-permissions，并按 commit 记录输出。prompt 要求 Claude 拆分问题、追踪进度并持续推进。作者打趣道：“循环会永远运行，不过有一次我看到 Claude 不小心执行 pkill -9 bash，把自己杀掉了。”
并行运行 Claude
多个并行实例同时解决两个限制：单个 session 一次只能做一件事，而多个 Agent 可以专门化。
实现方式是创建 bare Git repository，并为每个 Agent 提供一个挂载仓库的 Docker container。每个 Agent clone 本地副本、工作后将变更 push 到 upstream。一个简单同步算法避免冲突：
- Claude 向
current_tasks/写入文本文件，以“锁定”任务。若两名 Agent 同时领取同一任务，Git 同步迫使后一名选择其他任务。 - Claude 完成工作、从 upstream pull、merge 变更、push，然后移除锁。merge conflict 很常见，但 Claude 能处理。
- 无限循环会在新的 container 中启动新的 session。
没有 orchestrator Agent；每个 Claude Agent 独立决定怎么做，通常选择“下一个最显而易见”的问题。
使用 Claude Agent 团队编程的经验
编写极高质量的测试
Claude 自主工作，因此“任务 verifier 必须近乎完美，否则 Claude 会解决错误的问题”。作者构建 CI pipeline，并在发现失效模式后持续收紧约束。
站在 Claude 的角度设计
test harness 是为 Claude 而不是人设计的。说明要求维护完整 README，并高频更新 progress file。设计围绕 LLM 的固有限制展开：
- Context window pollution。 Harness 不应打印数千无用字节。重要信息应写入 log file，且日志要便于处理，例如“若有错误，Claude 应写入
ERROR，并在同一行给出原因，以便grep找到”；汇总统计应预先计算。 - Time blindness。 Claude 不能感知时间，“会乐于花数小时跑测试而不推动进展”。Harness 因而提供
--fast，运行 1% 或 10% 随机 sample；每个 Agent 内结果确定，但不同 VM 的 sample 随机。
让并行化足够简单
当有许多彼此独立的失败 test 时，并行化很直接：每个 Agent 领一个不同 test。通过率达到 99% 后，各 Agent 分别尝试编译不同的小型开源项目，例如 SQLite、Redis、libjpeg、QuickJS 和 Lua。
编译 Linux kernel 更难，因为它是单一巨型任务：所有 Agent 都可能遇到同一 bug 并覆盖彼此变更。解决办法是把 GCC 当作 oracle。新的 harness 随机让 GCC 编译大部分 kernel，仅让 Claude compiler 编译其余文件，使不同 Agent 能修复不同文件的 bug。两个文件合在一起失败、单独却成功时，仍需 delta debugging。
多种 Agent 角色
并行也带来专业化：一个 Agent 合并重复代码，一个提升 compiler performance，另一个专注生成高效 compiled code，一个以 Rust developer 视角批评设计，另一个负责 documentation。
压力测试 Agent 团队的边界
该项目也可视作能力 benchmark。此前 Opus 4 系列几乎不能写出可用 compiler；“Opus 4.5 是第一个跨过门槛、能产出可通过大型 test suite 的功能 compiler 的模型”。随后以 Opus 4.6 继续向前测试。
评估
两周内近 2,000 个 session 中，Opus 4.6 消耗 20 亿 input token、生成 1.4 亿 output token，成本略低于 20,000 美元。这是 clean-room implementation，不联网，只依赖 Rust standard library。
100,000 行 compiler 可在 x86、ARM、RISC-V 上构建可启动 Linux 6.9；还可编译 QEMU、FFmpeg、SQLite、Postgres、Redis，在多数 compiler test suite（包括 GCC torture test suite）上达 99% pass rate，并能编译、运行 Doom。
限制包括：
- 缺少 Linux 脱离 real mode 所需的 16-bit x86 compiler，因此该部分调用 GCC；
- 没有自有 assembler 和 linker，二者仍存在问题，演示使用 GCC 的 assembler 与 linker；
- 能构建很多项目但不是全部，尚不是现实 compiler 的 drop-in replacement；
- 生成代码效率低于关闭全部 optimization 的 GCC；
- Rust 代码质量尚可，但远未到 expert 水平。
Compiler 几乎触及 Opus 的能力边界：“新 feature 和 bugfix 经常破坏已有功能。”特别困难的是 16-bit x86 code generator。Opus 虽能通过 opcode prefix 输出正确 16-bit x86，但输出超过 Linux 强制的 32k code limit，因此 Claude 让 GCC 处理 x86；ARM 与 RISC-V 则完全自行编译。
展望
作者认为 Agent 团队展示了“自主实现完整复杂项目的可能性”，让用户可以设定更有雄心的目标。但全自主开发也有真实风险：test 全部通过时，人们很容易以为工作完成，“但这很少是真的”。他既兴奋也不安，认为“程序员部署从未亲自验证的软件”确实值得担忧。
快速进展打开了编写大量新代码的大门，积极用途预计会超过负面影响，但仍需要新的策略来安全驾驭。
致谢
感谢 Josef Bacik、Edwin Chen、Bernardo Meurer Costa、Jake Eaton、Dan Kelley、Felix Klock、Jannet Park、Steve Weis 以及 Anthropic 的其他同事。